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Graceful OSPF Restart Implementation Report 

Status of This Memo 
This memo provides information for the Internet community. It does 
not specify an Internet standard of any kind. Distribution of this 
memo is unlimited. 

Copyright Notice 
Copyright (C) The Internet Society (2005). 

Abstract 
Graceful OSPF Restart, as specified in RFC 3623, provides a mechanism 
whereby an OSPF router can stay on the forwarding path even as its 
OSPF software is restarted. This document provides an implementation 


report for this extension to the base OSPF protocol. 
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Overview 


Today, many Internet routers implement a separation of control and 
forwarding functions. Certain processors are dedicated to control 
and management tasks such as OSPF routing, while other processors 
perform the data forwarding tasks. This separation creates the 
possibility of maintaining a router's data forwarding capability 
while the router’s control software is restarted/reloaded. For the 
OSPF protocol [OSPF], the protocol mechanisms necessary to accomplish 
this are described in Graceful OSPF Restart [GRACE]. 


This document satisfies the RFC 1264 [CRITERIA] requirement for a 
report on implementation experience for Graceful OSPF Restart. 
Section 2 of this document contains the results of an implementation 
survey. It also documents implementation differences between the 
vendors responding to the survey. Section 3 contains a MIB 
reference. Section 4 provide an authentication reference. Section 5 
simply refers to the implementations listed in section 2. Section 6 
includes a minimal set of test scenarios. Finally, section 7 
includes a disclaimer with respect to operational experience. 


Implementation Experience 


Eleven vendors have implemented graceful OSPF and have completed the 
implementation survey. These include Redback, Juniper, Motorola 
Computer Group (formerly Netplane Systems), Mahi Networks, Nexthop 
technologies, Forcel0 Networks, Procket, Alcatel, Laurel Networks, 
DCL (Data Connection Limited), and Ericsson. All have implemented 
restart from the perspective of both a restarting and helper router. 
All but one vendor implemented both planned and unplanned restart. 


All implementations are original. Seven successfully tested 
interoperability with Juniper. Juniper successfully tested 
interoperability with Forcel0 Networks. One vendor tested with John 
Moy’s GNU Public License implementation [OSPFD]. Two vendors had not 


tested interoperability at the time of the survey. 


1. Implementation Differences 


The first difference was whether strict LSA checking was implemented 
and, if so, whether it was configurable. In the context of graceful 
OSPF restart, strict LSA checking indicates whether a changed LSA 
will result in the termination of graceful restart by a helping 
router. Four vendors made it configurable (three defaulted it to 
enabled and one to disabled), another made it a compile option 
(shipping with strict LSA checking disabled), another didn’t 
implement it at all, and five implemented strict LSA checking with no 
configuration option to disable it. 
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The second was whether a received grace LSA would be taken to apply 
only to the adjacency on which it was received or to all adjacencies 
with the restarting router. This is a rather subtle difference since 
it only applies to helping and restarting routers with more than one 
full adjacency at the time of restart. Eight vendors implemented the 
option of the received grace LSA only applying to the adjacency on 
which it was received. Three vendors applied the grace LSA to all 
adjacencies with the grace LSA originator (i.e., the restarting 
router). 


The final difference was in whether additional extensions were 
implemented to accommodate other features such as protocol 
redistribution or interaction with MPLS VPNs [VPN]. Five vendors 
implemented extensions and six did not. It should be noted that such 
extensions are beyond the scope of Graceful OSPF Restart [GRACE]. 


3. MIB Reference 


MIB objects for the Graceful OSPF Restart have been added to the OSPF 
Version 2 Management Information Base [OSPFMIB]. Additions include: 


- Objects ospfRestartSupport, ospfRestartInterval, ospfRestartAge, 
ospfRestartExitReason, and ospfRestartStrictLsaChecking to 


ospfGeneralGroup. 


- Objects ospfNbrRestartHelperStatus, ospfNbrRestartHelperAge, and 
ospfNbrRestartHelperExitReason to ospfNbrEntry. 


- Objects ospfVirtNbrRestartHelperStatus, 
ospfVirtNbrRestartHelperAge, and 
ospfVirtNbrRestartHelperExitReason to ospfVirtNbrEntry. 


4. Authentication Mechanisms 


The authentication mechanisms are the same as those implemented by 
the base OSPF protocol [OSPF]. 


5. List of Implementations 
Refer to section 2. 

6. Test Scenarios 
A router implementing graceful restart should test, at a minimum, the 
following scenarios as both a restarting and helping router. For all 


scenarios, monitoring data plane traffic may be used to ensure that 
the restart is non-disruptive: 
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1. Operation over a broadcast network. 

2. Operation over a P2P network. 

3. Operation over a virtual link. 

4. Operation using OSPF MD5 authentication. 


5. Early graceful restart termination when an LSA inconsistency is 
detected. 


6. Early graceful restart termination when a flooded LSA changes (if 
implemented). 


Operational Experience 


Since OSPF graceful restart is configurable, it is difficult to gage 
operational experience at this juncture. However, multiple service 
providers have tested and evaluated it. 


Security Considerations 


This document does not discuss implementation and interoperability 
aspects of the security mechanisms in great detail, as no new 
security mechanisms are introduced with Graceful OSPF Restart. 
Security considerations for the OSPF protocol are included in RFC 
2328 [OSPF]. Security considerations for Graceful OSPF Restart are 
included in [GRACE]. 
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Full Copyright Statement 
Copyright (C) The Internet Society (2005). 


This document is subject to the rights, licenses and restrictions 
contained in BCP 78, and except as set forth therein, the authors 
retain all their rights. 


This document and the information contained herein are provided on an 
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 


Intellectual Property 


The IETF takes no position regarding the validity or scope of any 
Intellectual Property Rights or other rights that might be claimed to 
pertain to the implementation or use of the technology described in 
this document or the extent to which any license under such rights 
might or might not be available; nor does it represent that it has 
made any independent effort to identify any such rights. Information 
on the procedures with respect to rights in RFC documents can be 
found in BCP 78 and BCP 79. 


Copies of IPR disclosures made to the IETF Secretariat and any 
assurances of licenses to be made available, or the result of an 
attempt made to obtain a general license or permission for the use of 
such proprietary rights by implementers or users of this 
specification can be obtained from the IETF on-line IPR repository at 
http://www.ietf.org/ipr. 


The IETF invites any interested party to bring to its attention any 
copyrights, patents or patent applications, or other proprietary 
rights that may cover technology that may be required to implement 
this standard. Please address the information to the IETF at ietf- 
ipr@ietf.org. 
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